Better release candidate logic #370
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
One thing that would be good to add to This ( |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a little suite of JS (CLI) scripts to manage bumping versions for all updated (according to Lerna, anyway) packages in a given release candidate.
script/get-packagescan more reliably get (and list, when run directly) all of the package directories by un-globbing the patterns inlerna.jsonand filtering the matched files by whether they contain apackage.json. Previously, we were doing this with hard-coded globs likemodules/*, which broke down as soon as we introduced thetoolsdirectory.script/get-release-versioncan be used to test that the release version we think we should be publishing is correct, and warns if theprimer-css/package.jsondoesn't match. E.g. if we're on therelease-9.6.0branch and theversionfield inprimer-css/package.jsonisn't9.6.0, then we should see a warning in the CI output.script/release-candidateis now a Node script that uses the two above scripts (as JS imports) to list the packages and determine the correct release version, filters by the list that Lerna thinks are "updated", and "reserves" a prerelease for each with thercidentifier by incrementing the-rc.xsuffix until it finds an un-published version on npm. Finally, for each updated module, it updates all of the dependent package versions in theirdependenciesfields so that the published release candidate references all of the . I'm fairly certain that this is not 100% bullet-proof because it doesn't "correctly" walk the entire dependency tree, but it's way better than what we had before.I've also moved the Yeoman generator into the
toolsdirectory to test this out./cc @primer/ds-core